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ABSTRACT 


Currently the Naval Postgraduate School's Alumni 
Database houses the records of nearly twenty-six thousand 
alumni, however there are over fifty thousand more records 
that need to be added. Although a database currently 
exists that attempts to fulfill many of the requirements of 
an alumni system, it has been determined that overall the 
current database is inadequate. A need exists to either 
modify or replace the current system to ensure that all of 
the Naval Postgraduate School's alumni relation needs are 
met. A decision is being pondered about whether the 
creation and management of such a system should be done 
within the confines of the school or outsourced to another 
organization, this thesis will aid in that decision making 
process. Throughout this study, evaluations are made on 
the feasibility of having an alumni system, and the most 
cost effective way to obtain it. Assessments and 
recommendations are also made on issues involving security, 
accessibility, and the responsibilities of the system's 
users, as well as the system. In its entirety, this thesis 
will serve as a foundation for those who will determine how 
the Naval Postgraduate School will proceed in finding a 
solution to its alumni needs. 
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INTRODUCTION 


I. 


A. BACKGROUND 

Established in 1909, the Naval Postgraduate School 
began as a small graduate school specifically designed to 
educate military officers. Through its transition from 
Annapolis, Maryland to Monterey, California, and throughout 
its existence there have been thousands of students who 
have matriculated at the institution. Since most of these 
graduates have served, or will continue to serve in many 
different military and civilian capacities, therein lays a 
valuable reservoir of knowledge waiting to be accessed. 
This knowledge is important to the Naval Postgraduate 
School for several reasons that range from conducting 
alumni surveys to generating ideas and answers to various 
research issues. Over the past fifteen years various 
attempts have been made to construct a way to access this 
knowledge and to stay connected with the graduates, 
however, a glaring void still exists in this arena. 

Currently, there is no effective medium that exists 
that allows the Naval Postgraduate School's staff and 
faculty to stay connected with the school's alumni. 
Naval Captain Jeff Kline of the Graduate School of 
Operations and Information Science, Dean Douglas Brook of 
the Graduate School of Business, and Naval Commander Sue 
Higgins, a faculty member in the Space Systems curriculum, 
agree that by having an effective system, all departments 
within the school would be able to obtain more feedback on 
real world issues and problems that dominate the business 
world, as well as the fleet. Dean Brook also suggests that 
tracking how well the school is progressing as a learning 
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institution would also be easier to accomplish with a more 
effective system available. He notes that although some 
processes may be accomplished by the current system, the 
advantages created by a more diverse and user-friendly 
system would be nearly limitless. 

Group mail-outs to alumni and former staff, as well as 
daily, weekly, or monthly updates of the changes being made 
at the school would also be an activity greatly facilitated 
by a more effective system. Presently the possibility of 
these updates being done by one central system does not 
exist, however they are being attempted through various 
means that are seen by only a small fraction of its 
intended audience. With a new and more effective system, 
files would be managed and maintained electronically which 
would allow for greater accessibility, usability, and 
visibility. 

Additionally, Amy Crain of the Naval Postgraduate 
School Foundation estimates that because of the current 
system's inability to foster relationships and connections, 
the Naval Postgraduate School Foundation, Incorporated has 
missed the opportunity to raise hundreds of thousands of 
dollars in fundraising and donations, donations that could 
be used for things such as supplementing student housing 
costs or assisting in guest speaker costs. She estimates 
that with a competent and effective system in place, 
fundraising could reach nearly seventy-five percent more 
potential donors than are currently being reached. This 
increased outreach would not only benefit fundraising 
totals, but would also establish a connection where other 
information could be shared. 
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B. 


RESEARCH ISSUES 


From these areas of concern it is evident that a void 
still exists in the Naval Postgraduate School's alumni 
system. This thesis will focus on filling that void by 
detailing requirements for a Web-enabled alumni information 
system that will allow the executive staff, faculty, and 
alumni of the Naval Postgraduate School to stay connected 
even after they have departed from the institution. In 
order to create such a system, however, several problems 
must be addressed and resolved. 

• How to design an effective and user-friendly 

system. 

• Identify who the main stakeholders of the system 
are, and how they will interact with the system. 

• How to evaluate the costs and benefits of 

outsourcing such a system compared to developing 
the system in-house. 

• Determine which alternative best accomplishes the 
goals of the Naval Postgraduate School. 

• How to design a system that allows for group 

modifications to be accomplished and information 
to be shared amongst its users. 

• How to design a system that can interact with 

other NPS systems. 

• How to design a security structure to safeguard 
the integrity of the data. 

C. METHODOLOGY 

To gain knowledge on how alumni information was 
acquired and maintained in the past, several research 
techniques were used. Because much of the history 

surrounding the Naval Postgraduate School's alumni system 
is not well documented, a significant number of telephone 
and personal interviews were conducted to solicit 
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information and knowledge about past and future systems. 
Interviews were conducted ranging across the spectrum from 
representatives of potential outsourcing companies to key 
representatives of the major stakeholders that have a 
specific interest in the development of the system. 
Internet resources, books written that were relevant to 
this topic, previous theses, and other relevant 
publications were also used to gather preparatory 
information. 

Research was done to design a system that allows group 
modifications, and also to design a system that allows for 
information to be shared, maintained, and accessed by 
multiple users. 

Determining who will utilize the alumni database, how 
it will be used, and the responsibilities of those using 
the system are also major issues surrounding the 
implementation of a new system. An important deliverable 
of this thesis is the description of all the major 
participants in the process and how they will interact with 
both the system, and one another. As a result of 
stakeholder interviews and research of past usages and 
requirements, we have developed use cases, which are 
textural narrative descriptions, for each of the main 
usages for this system and have documented user 
responsibilities in ensuring that the system is adequately 
maintained. We have also developed actor/use case diagrams 
that illustrate the interactions between the users and the 
system on a daily or weekly basis. Access criteria have 
also been produced to determine who requires access to the 
system and what types of access they will be granted. 
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The ability of the new system to relate and interact 
with other systems is another concern that has been 
addressed. Because of the diversity of the Naval 
Postgraduate School's systems, led by the PYTHON Student 
Management System, measures need to be taken to ensure that 
any alumni system that is designed needs not only to 
interact with the important existing systems, but should 
also be able to replace many of the ad hoc and legacy 
systems that are being used to extract and utilize alumni 
information campus-wide. This can only be done if a 
concise, user-friendly system is created. A study was 
conducted to determine the levels of compatibility that the 
alumni system must have to coexist with other NPS systems, 
and how its development may result in other departments 
discontinuing the usage of their ad hoc alumni systems. 

Also, a survey was conducted to determine if there was 
any interest in having a new system introduced. A cost- 
benefit analysis was also conducted to determine if the 
costs of creating a new system was feasible for the school. 
In the study, the benefits and costs of maintaining and 
managing the system in-house are compared to outsourcing 
that responsibility to an outside agency. 

When designing an interactive database that primarily 
contains information about military personnel, the need for 
security is patently obvious. Research was done to both 
identify the inherent risk associated with this project, 
and to identify the risks that are a part of all 
interactive Internet projects. This thesis offers possible 
solutions to address and mitigate the risks that are 
associated with this subject. 
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D. STRUCTURE OF THE THESIS 

Following the conclusion of this chapter, the thesis 
will flow in the following sequence. Chapter II will 
chronicle the history of past attempts made at building an 
adequate system. A snapshot will be provided that details 
past submissions and their shortfalls. Chapter III will 
focus on whether the need even exists for an alumni system. 
Survey results will be provided to illustrate that 
potential users feel that there is a need for the system at 
the school. Also, cost-benefit analysis results will be 
provided to show the potential advantages and disadvantages 
of the system, and the options currently being explored to 
get the usability of the system back to an acceptable 
level. Chapter IV will take a look at how the actual 
system should look and be set up. Information will be 
provided detailing how the system will interface with the 
current systems at the Naval Postgraduate School, 
specifically the PYTHON Student Management System. Use 

cases will be provided to establish a guideline for how 
users will interact with the system, and how the system 
will respond to those actions. Also, access criteria will 
be provided along with a list of user responsibilities to 
show the different access levels, what that level will 
entail, who should be granted that level, and their 

responsibilities to the system. Questions concerning 

security will be presented with possible solutions to 
mitigate concerns. In chapter V, we summarize the work 
accomplished, provide a list of system requirements, and 

conclude with other system recommendations. 

Over the past fifteen years a significant amount of 
progress has been made in constructing a flexible and 
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effective alumni system, however to date, no system has 
been designed that ensures that alumni information is 
centrally located, easily accessed, easily modified, and 
easily managed. This thesis will attempt to bring the 
Naval Postgraduate School closer to that goal. 
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II. HISTORY OF THE ALUMNI DATABASE SYSTEM 


For many years the Naval Postgraduate School has 
struggled to find ways to locate and remain connected with 
those who have attended and graduated from the school. In 
an effort to provide a point of reference for how the Naval 
Postgraduate School's Alumni System has evolved over the 
last couple of decades, a brief snapshot of its history is 
provided in Figure 1. Although many of the details of 
previous systems will be excluded, some of the problems 
encountered by those systems will be shown to provide 
further evidence of why an updated or new system is needed. 


2000 

ALUMNI DATABASE TIMELINE International Assoc. 

Website goes Public 



1980 2002 


Figure 1. Alumni Database Timeline 


The Naval Postgraduate School's first known foray into 
the alumni relations arena came in the early 1980s, which 
is when the school instituted its first alumni management 
system with the intent of staying in contact with the 
school's graduates. The manual system that was designed 
and implemented during that time turned out to be very 
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tedious, inefficient, and difficult to manage. The 
majority of past and present student records that were 
maintained were kept alphabetically in filing cabinets 
located in the Office of the Registrar. When it was 
determined that a record required modification or 
cancellation, attempts were made by the Registrar's Office 
to make the necessary changes, however because the records 
had to first be located, and then manually updated, often 
times the changes never occurred. Several factors 
contributed to this inefficiency, but most frequently this 
lack of progress resulted from an inadequate amount of 
personnel, and the sheer volume of the records that had to 
be searched to locate those requiring adjustments. This 
resulted in thousands of records that were either outdated 
or invalid. 

In 1986, the school made a second effort to address 
the alumni situation. It decided that maintaining the 
records of all the graduates electronically rather than 


manually 

would better prepare 

the 

institution 

for 

the 

future. 

During 

the fall of 

1986, 

the Office 

of 

the 

Registrar 

started 

keeping electronic 

records of 

all 

the 


Naval Postgraduate School graduates. Although the burden 
of having enough physical space to house all the records 
had been lifted, several challenges still existed. One 
problem resulted from the conversion of paper records to 
electronic ones. The combination of incomplete and 

inaccurate material contained in the hard copies along with 
user input error resulted in the database being heavily 
populated with erroneous data, which is still evident in 
the current system. Also, the time and effort it took to 
convert the records played a key role in delaying the 
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system's usability. It would have required nearly around- 
the-clock input by several clerks to convert the 
approximately forty thousand existing records; therefore 
many records are still only available in hard copy format. 

By the end of the 1980's users realized that they 
still were not getting what they wanted or needed from the 
system, so in 1992, after attempting several manual and 
electronic alternatives to contact past and present 
graduates, another effort was made to automate the entire 
alumni system. The project turned out to be quite 
extensive and involved several organizations, primarily the 
NPS Office of the Registrar, the NPS Alumni Association, 
and the NPS Foundation. These entities, along with several 
others, tried to create an NPS alumni database that would 
not only store all of the alumni records, but also allow 
for the completion of many different functions ranging from 
printing simple reports to running basic information 
queries. In late 1992, the official NPS Alumni Database 
was established and made available to the school's alumni. 
The system had been designed utilizing a Focus program and 
was expected to be more effective and efficient than 
previous attempts. In addition to having extensive 
storage capabilities and the ability to complete basic 
functions, the database was intended to easily accommodate 
both record modification and cancellation; unfortunately 
this was never accomplished. Although this system solved 
some of the problems that previous systems did not address, 
the system still did not allow records to be searched using 
designated fields. Also, records could still only be 
accessed on an individual basis. Although modifications to 
individual records could be done, they were difficult to 
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accomplish, and the ability of make group modifications was 
still not available. The system was also not very user 
friendly; in fact the Deputy Associate Provost stated that, 
if a user did not have significant knowledge about Focus, 
he believed it was virtually impossible to extract 
meaningful data out of the system. Although this 

particular attempt proved to have very limited 
capabilities, it did have a positive impact on the 
development of later systems. This failed system laid the 
groundwork necessary for future attempts at designing an 
effective alumni system. 

Following the lead of other prestigious graduate level 
institutions, NPS leaders recognized an increasing need to 
establish alumni connections, so in 1997 an Alumni 
Relations Office was established. Because the existing 
system at that time did not allow the Naval Postgraduate 
School the access that it wanted or needed, another attempt 
was made in 1998 to get a handle on the alumni problem by 
creating a relational database that utilized Structured 
Query Language (SQL). This database was intended to 
incorporate all the alumni-related information made 
available from several sources around campus and to store 
it in one general location. To populate this database 
system, information would be supplied from several sources: 

• The Focus database that had been used in the 
early 1990's. The information from this database 
would be used to supply data about present 
students, as well as the limited number of 
graduates that had been entered into the system. 
Although this system had not performed well, much 
of its information had proven to be reliable; 
therefore it was transferred to the relational 
system. 
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Outsourcing. Bernard C. Harris Incorporated, a 
computer service company, had been hired by the 
school to conduct a poll to locate past graduates 
whose manual records had been deemed incomplete 
or inaccurate. Harris' findings, once verified, 
also served as a source of information for this 
database. Universal Internet, another computer 
firm, who had been hired by the NPS Alumni 
Association to work on creating an alumni 
management system, also had pertinent information 
that needed to be transferred to the relational 
database. 

The Alumni Relations Office. The ARO had been 
maintaining information on current students and 
recent graduates by maintaining manual checkout 
and update sheets, and was also supplying the 
relational database with information. 


With this wide variety of information being supplied 
by several sources, the job of those commissioned to 
develop the relational system became increasingly 
difficult. Furthermore, soon after the project began, many 
of the NPS leaders who had initiated the process were 
beginning to transfer or retire, which caused a lapse in 
momentum and direction. 

Once modifications to the system began to occur, a 
bevy of new expectations began to surface. One of the most 
important changes that developed from this turnover was the 
evolving definition of an alumnus. The new leaders decided 
that not only should the new system track students 
obtaining master degrees, but it should also incorporate 
those students who were attending and eventually graduating 
from one of the many short programs that the school 
offered. In addition to traditional master's degree 
students, graduates of these short programs were now going 
to be considered school alumni as well. This new 
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definition and requirement deterred many faculty members 
and caused the scope of the project to increase to the 
extent that most involved believed that a valid system 
could not be created or accurately maintained. 

In March 2000, the NPS Alumni Association, in 
conjunction with Universal Internet, launched the 
International Alumni Association website, which provided 
access to the alumni database. This relational database 
was much like its Focus predecessor, and it addressed many 
of the problems that had existed, however there were still 
other issues not being adequately addressed. One issue of 
great importance was that the relational database did not 
have robust search capabilities. According to Alumni 
Relations Office, this system was also not very user 
friendly. This was primarily because the system was being 
geared toward fundraising. Although the school's alumni 
were the main focus in this system, many others, such as 
retired military and interested civilians, were also 
included in the database. This frequently caused confusion 
and problems for the system's users. Also, without having 
prior knowledge of relational systems or how to structure 
search criteria, users found it difficult to retrieve 
desired information. 

Another problem that surfaced involved the various 
sources of information that were being utilized. Because 
the information that the system was intended to use came 
from several places, problems arose around the lack of 
standardization in the way records were being maintained. 
Because some records were stored utilizing student names, 
and others were stored utilizing file numbers or social 
security numbers, the system and its users were 
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understandably confused. There were no standardized fields 
common across the various sources and this resulted in 
corruption of the system and its ability to provide 
meaningful and truthful data. 

Later in 2000, the Alumni Relations Office began 
conducting studies looking at ways to create a more 
efficient and effective alumni system. During this process 
it was realized that while the SQL system had served as a 
significant stepping-stone in the overall alumni process, 
something else was needed to take alumni relations to the 
next level in accessibility, maintainability, and 
manageability. 
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Ill. 


ANALYSIS OF FINDINGS 


In the early stages of its development in the 1980's, 
the Naval Postgraduate School's Alumni System was faced 
with several challenges. Because those in charge of making 
crucial decisions in determining its implementation were 
skeptical, supporters of the system were required to 
document reasons why they felt it was necessary, and the 
added value that it would provide to the institution. In 
2000 that entire process seemed to go full circle as Naval 
Postgraduate School leaders again asked those committed to 
an alumni system to justify the need for having a new or 
updated one, and again supporters began preparing 
explanations of why the system was, in their eyes, 
important and necessary. NPS officials were asking the 
tough questions because, prior to obligating more money to 
an ineffective system, they were trying to ensure that an 
updated or new system was really beneficial to the school. 
They wanted to understand the value that the system might 
generate, and to determine how much the system would cost. 
Over the course of the past year, we conducted interviews 
and mailed out surveys that address these specific 
questions. 

A. SURVEY: PURPOSE 

A survey was mailed out to individuals at the Naval 
Postgraduate School that either had experience in using 
past alumni systems, or a significant interest in the 
creation of a more effective system. The fifteen 
individuals selected to participate in this survey are 
listed in Figure 2. These individuals were identified by 
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members of the Alumni Relations Office to be key 
representatives of the major stakeholders in the Naval 
Postgraduate School Alumni System. 


NAME 

TITLE/DEPARTMENT 

Christopher Arias 

Student Services Officer, SSO 

Tracy Hammond 

Deputy Associate Provost, Registrar 

Amy Crain 

Director of Operations, NPS Foundation 

Danielle Kuska 

Director of Research Administration 

Rudy Panholzer 

Dean, GS of Eng. & Computation 

Jeff Knorr 

Professor & Chairman, Eng.& Computation 

Bill Hatch 

Acad. Assoc., GS of Bus.& Public Policy 

Jeff Kline 

Associate Dean, GS of Info. Science 

Charles Calvano 

Professor, GS of Mechanical Engineering 

Rob Bourke Jr. 

Alumni Relations Officer 

Sue Higgins 

Military Faculty, Space Systems 

Douglas Brook 

Dean, GS of Bus. & Public Policy 

Gary Roser 

Director of International Programs 

Bob Osterhoudt 

President, Alumni Association 

Julie Filizetti 

Exec. Director of Institutional 

Advancement & Communications 


Figure 2 . 


Survey List 
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The key representatives were asked several questions 
on the importance of an alumni system. Responses were 
ranked on a scale from 1 (least important) to 5 (most 
important) in order of importance, and are listed in Figure 

3. 


Do you feel an alumni system is needed at the Naval 
Postgraduate School? 

Definitely Needed 60% 

Greatly Needed 20% 

Somewhat needed, but not required 20% 

How much will an alumni system be used by you and/or your 
department ? 

Daily 20% 

Weekly 40% 

Sparingly (few times a month) 40% 

Would an alumni system impact your job and 
responsibilities? 

Significantly 20% 

Somewhat 70% 

Not much 10% 

Quantify the potential usages for the system? 

Limitless 20% 

Very few limitations 60% 

May have some limits, but not significant 20% 

Would you promote using the system? 

Yes, would require it 60% 

Yes, would strongly suggest it 40% 


Figure 3. 


Survey Results 
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A list of important intangible features for an alumni 
system was generated from interviews that were conducted 
and research that was done. Individuals surveyed and 
interviewed were also asked to rank, on a scale from 1 to 
10, the importance of having these intangibles in a 
potential alumni system. The results are listed in Table 
1 . 


FACTOR 

Jeff 

Kline 

Amy 

Crain 

Bill 

Hatch 

Danielle 

Kuska 

Rudy 

Panholzer 

Jeff 

Knorr 

Tracy 

Hammond 

Julie 

Filizetti 

Charles 

Calvano 

AVERAGE 

Accuracy 

10 

10 

10 

10 

10 

10 

5 

10 

9 

9.3 

Reliability 

8 

10 

10 

10 

10 

10 

5 

10 

7 

8.9 

Ease of Use 

9 

10 

8 

6 

8 

8 

5 

8 

8 

7.8 

Affordability 

5 

8 

5 

6 

6 

10 

5 

9 

* 

6.8 

Interoperability 

7 

* 

8 

8 

5 

5 

3 

8 

* 

6.3 

Scalability 

5 

* 

5 

7 

4 

8 

5 

7 

« 

5.9 

Paperwork 

Reduction 

6 

5 

5 

5 

5 

8 

1 

8 

* 

5.4 

AVERAGE 

7.1 

8.6 

7.3 

7.4 

6.9 

8.4 

4.1 

8.6 

8.0 

*no value 
recorded 


Table 1. Critical Success Factors 

Although the survey is not a statistically designed 
instrument, it does provide preliminary indications that an 
alumni system is needed. Many of the respondents to the 
survey and those interviewed indicated that they believe 
that not only is an alumni system needed, but it is 
mandatory if the school wants to continue to be a 
competitive graduate institution. Also, many of the 
participants in the process indicated that such a system 
could have a noticeable effect on how they performed their 
job and the level at which it was performed. Although the 
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majority of those surveyed said that they would sparingly 
utilize the system, it is easy to infer that others with 
different responsibilities and interest may have an 
increased need to use the system. Most also felt that the 
system was nearly limitless in ways in which it could be 
used and the effect that it would have on the school. Some 
feel that past alumni systems have failed because of a lack 
of interest and because of how old systems were promoted. 
According to the survey results, if an effective product is 
developed, promotion or the lack thereof would be a non¬ 
issue. Many of the participants indicated that they would 
not only promote the usage of the system, but would require 
it. 

Although the survey results provided indications of 
the potential an effective system might have, the results 
were not conclusive. This suggests that further 
requirements analysis as is warranted. Accordingly, the 
next step we undertake is a cost-benefit analysis. An 
economic analysis is a systematic approach to evaluating 
alternative projects. Underlying such an analysis is the 
base assumption that each alternative may be able to solve 
an existing problem and should produce certain results 
while requiring and utilizing certain resources. In this 
particular situation, there are several options being 
considered to solve the problem. An economic analysis was 
performed on each of these options to determine the 
comparative costs and benefits, and to determine which 
alternative is the most appealing from this perspective. 

B. COST-BENEFIT: PURPOSE 
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There are several options being considered for the 
alumni database system at the Naval Postgraduate School. 
They include: 

• Updating and utilizing the existing SQL 

relational database 

• Outsourcing the creation, population, hosting, 
and management of the system to one of the 
following vendors: 

• Bernard C. Harris Publishing Inc. 

• Sungard BSR 

• JSI Fundraising Inc. 

The Naval Postgraduate School Alumni Database, a SQL 
relational database, is the system currently installed at 
the Naval Postgraduate School for alumni relations. The 
problems with this system are extensive and have been 
detailed in previous chapters. In short, the system 
contains several shortfalls, primarily with its usability 
and adaptability. It has also become outdated and will not 
allow important processes to be successfully completed that 
are necessary in today's alumni environment. One option 
being considered to address the alumni system problem is 
updating the SQL system that currently resides at the 

school. There are several advantages and disadvantages to 
this option and these will be discussed later. 

Outsourcing the management of the alumni database to 
an organization outside of the Naval Postgraduate School is 
another distinct possibility being considered. At the 
outset of this thesis, there were several corporations that 
were being considered for the job, since then however, the 
possible contractors have been whittled to the three 
corporations listed above. These three companies have 
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provided information that indicates that they may have the 
ability to furnish NPS with an adequate alumni system. 


C. DISCUSSION 

All options were analyzed by utilizing the following 
methodology: 

• An assessment of the advantages and disadvantages 
of each option. 

• A cost breakdown of each option and comparison 
across options. 

• An evaluation of the intangible factors as they 
apply to the options. 

• A calculation of the Net Present Value (NPV) for 
each option. 

The following data were used to calculate NPV for all 
options: 

• Discount Rate: 10% (when evaluating investment 

projects that will continue for more than three 
years in a government organization, discounting 
should be used if at all possible. The 

prescribed Department of Defense discount rate 
for evaluating alternatives is 10%) . 

• Initial Costs: paid upfront at "Time Zero" 

• Recurring Costs: paid at the beginning of the 

year, starting in year 1 

• Life Cycle: 5 years 

• Scrap Value: zero for any hardware used 


1. Option 1: Updating the Existing SQL Relational 
Database 

This option involves updating the SQL relational 

database that currently exists. The chief advantage in 
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this option appears to be the costs associated with 
revamping the currently ineffective system. Familiarity is 
another advantage of this option. Because the system has 
evolved into its present state, those who have been around 
and understand how to use it are comfortable and should be 
benefited by utilizing a system they know. However, the 
advantages of this option could very easily become 
disadvantages if the work required to make the system an 
adequate one is more labor intensive than currently 
expected by those familiar with the system. The 
possibility of having NPS graduate students take on the 
project was considered, however it was determined by a 
panel headed by members of the Alumni Relations Office that 
this option required a significant amount of time to 
organize and implement, which made the option not feasible. 

The disadvantages of selecting this option are 
considerable. The primary disadvantage of updating the SQL 
system is that the expertise needed to create and maintain 
such a system in-house currently does not exist and is 
unavailable here at the school. Although updating the 
system would address some of the current system's problems, 
several others will continue to remain unless a significant 
amount of money is spent to make the system error-free. 

The approach used to assess this option uses estimated 
costs of maintaining and updating the SQL system, manpower 
operating costs, and the processing of all paperwork 
associated with the system. The cost analysis for this 
option is displayed in Tables 2-4. There is a hint of 
subjectivity on all assessments, however, all assessments 
made are based on individual interviews, interviews of 
potential outsourcing companies, and research. 



Factor 


Assessment 


Average _ Computed Value 


Accuracy 

4 

9.3 

37.2 

Reliability 

5 

8.9 

44.5 

Paperwork Reduction 

3 

5.4 

16.2 

Interoperability 

6 

6.3 

37.8 

Ease of Use 

3 

7.8 

23.4 

Affordability 

9 

6.8 

61.2 

Scalability 

6 

5.9 

35.4 


TOTAL 


255.7 







NET PRESENT VALUE 


FIXED COSTS 

$ 10000 


INITIAL COSTS (Paid this 

year)$ 5000 


RECURRING COSTS 



Operating Costs 

$ 37000 


Time 

Absolute 

Discounted 

0 

$ 47000 

$ 47000 

1 

$ 47000 

$ 42723 

2 

$ 47000 

$ 38822 

3 

$ 47000 

$ 35297 

4 

$ 47000 

$ 32101 

5 

$ 47000 

$ 29187 

NET PRESENT VALUE 


$ 255130 


Table 4. Net Present Value for Option 1 

2. Option 2: Outsourcing; Bernard C. Harris 

Publishing Inc. 

This option has the potential to be very beneficial to 
the Naval Postgraduate School because Bernard C. Harris 
Inc. is very experienced in providing services to many of 
the nation's premiere educational institutions. Harris' 
expertise in this field is not easily matched, and 
selecting this option could garner a significant "bang for 
the buck". In its proposal, Harris vows to create a new 
system for the Naval Postgraduate School that will account 
for all of the requirements and risks associated with the 
project, and they will do so at a relatively inexpensive 
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price. In addition to offering a catered system, Harris 
has also indicated that they will assign technicians who 
will be solely dedicated to the Naval Postgraduate School's 
new system. Another advantage is that Harris has committed 
to doing what it terms as a "search and locate" for all 
past alumni whose records presently do not exist. This 
service is included in Harris' price quote. 

Many of the disadvantages of outsourcing the project 
to Harris is similar to the disadvantages of other 
outsourcing projects; loss of control to the vendor, 
reduction of in-house competency due to vendor dependency, 
and lack of security. A major inherent risk in outsourcing 
a project that involves military officer information is 
security. Harris proposes that it will alleviate all NPS 
security concerns, and adhere to DOD security criteria. 

The approach used to assess this option, in most 
instances, uses prices furnished by the company and 
commercial industry prices for hardware. Estimates are 
used to account for manpower costs when applicable. Fees 
submitted by Harris did not project past current year, 
therefore future year costs are estimates. The cost 

analysis for this option is displayed in Tables 5-7. 
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Factor 


Assessment 


Average _ Computed Value 


Accuracy 

9 

9.3 

83.7 

Reliability 

8 

8.9 

71.2 

Paperwork Reduction 

7 

5.4 

37.8 

Interoperability 

7 

6.3 

44.1 

Ease of Use 

8 

7.8 

62.4 

Affordability 

9 

6.8 

61.2 

Scalability 

8 

5.9 

47.2 


TOTAL 


407.6 






FIXED COSTS 

NET PRESENT VALUE 

$ 15000 


INITIAL COSTS (Paid this 

year) $ 22400 ($11200 at 

contract, $11200 at delivery) 

RECURRING COSTS 

Operating Costs 

$ 22400 


Time 

Absolute 

Discounted 

0 

$ 22400 

$ 22400 

1 

$ 37400 

$ 33997 

2 

$ 37400 

$ 30892 

3 

$ 37400 

$ 28087 

4 

$ 37400 

$ 25544 

5 

$ 37400 

$ 15863 

NET PRESENT VALUE 


$ 156783 


Table 7. Net Present Value for Option 2 

3. Option 3: Outsourcing; Sungard BSR 

This is a second option in outsourcing the system to 
an outside organization. A major advantage of the Sungard 
software is its robustness. Sungard's latest release in 
the market is the 8.2 version of its Smartcall system. 
Sungard has forecasted version 9.0 being released within 
the next year. Serving over twenty-thousand clients 

worldwide and forty-seven of the world's top fifty largest 
financial institutions, Sungard has definitely established 
itself in the unique systems market, which provides solid 
evidence that the company is up to the challenge of 
handling the requirements of the Naval Postgraduate School. 
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Sungard's Advanced System is a Windows based system that 
can utilize either a UNIX, Windows NT, or Windows 2000 
server running MS SQL Server, or Oracle 8.0.6 or higher. 

A major disadvantage of Sungard option lies in the 
cost associated with purchasing the system. Although 
Sungard would be able to accommodate the NPS requirements, 
things such as an online directory, additional technical 
support, and alumni website construction would require 
additional funding. These costs, in addition to other 
inherent outsourcing issues, cause this option to compare 
unfavorably with other options. 

The approach used to assess this option also uses 
prices furnished by the company and commercial industry 
prices for hardware. The cost analysis for this option is 
displayed in Tables 8-10. 


Factor 

Assessment 

Average 

Computed Value 

Accuracy 

10 

9.3 

93 

Reliability 

9 

8.9 

80.1 

Paperwork Reduction 

10 

5.4 

54 

Interoperability 

8 

6.3 

50.4 

Ease of Use 

10 

7.8 

78 

Affordability 

4 

6.8 

27.2 

Scalability 

9 

5.9 

53.1 

TOTAL 


7.2 

435.8 

Table 8. 

Intangible Factors 

for Option 3 



30 






TOTAL COST 




FIXED 






ITEM 

UNITS 

PER 

UNIT 


TOTAL 

Advance 





$ 54800 

Licensing 





$ 12000 
$ 66800 

RECURRING 






ITEM 

UNITS 

PER 

UNIT 


TOTAL 

Maintenance 





$ 23300 

Internet Interface 





$ 9900 

$ 33200 

TOTAL COSTS 





$ 100000 

Table 9. 

Total Cost 

for 

Option 

3 



NET PRESENT 

VALUE 



FIXED COSTS 

$ 66800 





INITIAL COSTS (Paid this 

; year)$ 54800 





RECURRING COSTS 






Operating Costs 

$ 37000 





Time 

Absolute 



Discounted 

0 

$ 54800 



$ 

54800 

1 

$ 100000 



$ 

90900 

2 

$ 100000 



$ 

82600 

3 

$ 100000 



$ 

75100 

4 

$ 100000 



$ 

68300 

5 

$ 100000 



$ 

62100 

NET PRESENT VALUE 




$ 

433800 

Table 10. 

Net Present Value 

for Option 3 





4. Option 4: Outsourcing; JSI Fundraising, Inc. 

This is the third option for outsourcing the 
maintenance and management responsibility of the Alumni 
System. The advantages of this option relate to JSI's 
track record in the fundraising arena. The company founded 
in 1978, promotes its new Millennium fundraising software 
as the solution to many of the Naval Postgraduate School's 
alumni problems. The sophisticated and versatile software 
is a Windows based product that is designed for educational 
institutions much like NPS, in fact several reputable 
educational and medical institutions are currently using it 
worldwide. 

The disadvantages of this option, in addition to those 
inherent in outsourcing, are that JSI specializes in 
fundraising and that is only a fraction of what an NPS 
alumni database will be required to do. Although JSI 
asserts that their system and staff can accommodate the 
requirements, their level of expertise in other areas 
required by the NPS system is questionable. Another 
disadvantage to the JSI proposal is that no plan was given 
to search and locate information about those alumni who 
currently do not exist in the database. If an effort were 
made to capture this information, it would have to be 
coordinated with another organization. Although JSI would 
provide significant advantages in fundraising, at first 
blush, the system that they propose does not seem flexible 
enough to handle all of the Naval Postgraduate School's 
requirements. Additionally, fundraising is not a priority 
of the Naval Postgraduate School. 
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The approach used to assess this option also uses 
prices furnished by the company and commercial industry 


prices for hardware. The cost analysis for this option is 
displayed in Figures 11-13. 


Factor _ 

Accuracy 

Reliability_ 

Paperwork 

Reduction_ 

Interopera bility 

Ease of Use 

Afforda bility 

Scalability 


Assessment 


Average 


Computed Value 


TOTAL 


338.6 


Table 11. 


Intangible Factors for Option 4 


FIXED 


TOTAL COST 


ITEM 

Millennium 
User license 
License for Oracle 


UNITS 


PER UNIT 


TOTAL 
$ 29000 
$ 6750 

$ 5000 

$ 40750 


RECURRING 


ITEM UNITS 

Browser Interface Module 
Maintenance 


PER UNIT 


TOTAL 
$ 10000 
$ 8600 
$ 18600 


TOTAL COSTS 


$ 59350 


♦Total Cost does not include cost for "search and locate" requirement 


Table 12. 


Total Cost for Option 4 







NET PRESENT VALUE 



FIXED COSTS 

$ 40750 



INITIAL COSTS (Paid this 

year)$ 40750 



RECURRING COSTS 




Operating Costs 

$ 29000 



Time 

Absolute 

Discounted 

0 

$ 29000 

$ 

29000 

1 

$ 59350 

$ 

53949 

2 

$ 59350 

$ 

49023 

3 

$ 59350 

$ 

44571 

4 

$ 59350 

$ 

40536 

5 

$ 59350 

$ 

36856 

NET PRESENT VALUE 


$ 

253935 


Table 13. Net Present Value for Option 4 

D. SUMMARY 

Initial Cost Comparison. The initial costs of 

modifying the current SQL system appears to be easily the 
most inexpensive of the options. However, because the 
current system will require such an extensive overhaul to 
get it to an acceptable level and to make it technically 
competitive with other options, modifying the system is not 
a logical choice. The next best choice, according to the 
initial cost statistics, is outsourcing the system to 
Bernard C. Harris Publishing Inc. 

Total Cost Comparison. Outsourcing the system 

requirement to Harris is the best choice in terms of the 
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total cost involved. Totaling $ 37,400, this option's 
nearest competitor totaled $9,600 more. Not only does this 
option have the most inexpensive costs, but it also has the 
lowest net present value. Again, although the Sungard 
system will provide many advantages, the total cost for 
selecting this system is the most expensive option 
considered. 

Comparison of the Intangibles. In the category of 
intangibles, the system offered by Sungard proved to be the 
highest scorer. With a total rating of 435.8, it is easy 
to understand why Sungard seems to be such a great fit for 
the Naval Postgraduate School. Modifying the current SQL 
system attained the lowest score of any of the options. 
Although the SQL option provided lower costs, the factors 
that are important to the stockholders probably will not be 
accommodated by the system. In the intangibles, Bernard C. 
Harris, Inc. was very competitive with Sungard as it 
obtained a rating of 407.6. JSI Inc. finished third with a 
rating of 338.6. A chart of all the options is listed in 
Table 14. 
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SUMMARY 

COMPARISON 



OPTION 

INTANGIBLE VALUE/ 
AVERAGE FACTOR 

TOTAL COST 


NPV 

1(Update DB) 

255.7 

/ 

5.1 

$ 47,000 

$ 

255,130 

2(Harris) 

407.6 

/ 

00 

$ 37,400 

$ 

156,783 

3(Sungard) 

435.8 

/ 

8.7 

$100,000 

$ 

433,800 

4 (JSI) 

338.6 

/ 

6.7 

$ 59,350 

$ 

253,935 


Table 14. Summary/Comparison of Options 

E. RECOMMENDATIONS 

As previously noted, there are several important 
factors that have an affect in determining which option 
provides the best fit for the Naval Postgraduate School. 
Although the overall cost of the system seems slightly more 
important than the intangibles, a comparison of a 
combination of the factors will decide which option is the 
most advantageous. 

Although JSI Inc. was not the leader in any of the 
categories presented, its expertise in fundraising and its 
experience with other educational institutions make it a 
reasonable option in the decision making process. However, 
JSI's lack of experience in other areas where an alumni 
database could be used, and its inability to accommodate 
"search and locate" procedures on approximately 20,000 
alumni not currently present in the Alumni Database, make 
this option less desirable. 
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Modifying the current SQL system is the most 
advantageous option with regard to initial costs and it is 
very competitive in total costs. However, this option is 
severely lacking in the intangibles, and since it is highly 
questionable if the expertise that is required to create 
and maintain the system is available at NPS, we believe 
this option is high risk and therefore inferior to other 
alternatives. 

Sungard offers a great product with a proven track 
record. The major problem with the system is its 
relatively high price. Although this system seems to be a 
great fit for the Naval Postgraduate School and excels in 
the intangibles, Sungard's total cost of $100,000 and its 
net present value exceeding $ 400,000 significantly reduces 
its desirability. 

Outsourcing the installation, population, and 
management of the Naval Postgraduate School's Alumni System 
to Bernard C. Harris Publishing, Inc. seems to be the most 
desirable choice according to the established evaluation 
criteria. On all fronts, this option is either the leader 
or is very competitive with the other options in every 
category. Harris, much like Sungard, has a proven product 
that has earned a solid reputation. With the lowest total 
costs and net present value of any of the options, and a 
very high score in the intangibles, we recommend that the 
Naval Postgraduate School pursue this option as its 
solution to an alumni system. 
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IV. 


SYSTEM REQUIREMENTS 


A. STAKEHOLDERS 

Now that we have determined that outsourcing the 
creation and management of the Alumni System in the near 
term is the most desirable option, we have system 
requirement issues that must be addressed. First, we must 
identify the key stakeholders in the system. The main 
stakeholders who have a vested interest in the design and 
implementation of an effective and efficient alumni system 
are listed in Figure 4. 


MAJOR STAKEHOLDERS 

Alumni Relations Office (ARO) 

Alumni Association 

Naval Postgraduate School Alumni 

Office of the Registrar 

Department of International Programs 

Naval Postgraduate School Departments 

Student Services 

Naval Postgraduate School Foundation 


Figure 4. 


Major Stakeholders 
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B. USE CASES 

Throughout the requirements analysis for the alumni 
system, we employ use cases, which are narrative documents 
that describe the sequence of events that occur when a 
system and user interact. Succinctly, use cases are 
stories or cases of how a system is used by its customers. 
In constructing the use cases input was obtained from many 
of the system's potential users, as well as its potential 
creators and managers. Many of the use cases provided 
within this thesis are basic function use cases, which show 
the essence of the alumni process and its fundamental 
motivation without providing an overwhelming amount of 
design detail. We decided that use cases were needed to 
ensure that the overall process was well understood and 
could be reviewed if required. A series of expanded use 
cases is provided in the appendix in Tables 17-27. 


C. DATABASE SCHEMA 

Also throughout performing the requirement analysis 
for the alumni system, a database schema was constructed. 
Although the schema provided should not be viewed as a 
final submission, it does establish a framework for future 
databases. Database schemas basically define the structure 
of a database. Schemas combine tables, relationships, 
domains, and the business rules that will be used in the 
database's functions, and they serve as foundations upon 
which database applications are built. In designing the 
database schema for the alumni system, input was solicited 
from potential system users and managers. Those 

individuals were asked questions that pertained to what 
type of alumni information was most important to them, what 
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reports were expected to be generated by the system, what 
queries were expected to be performed, and what they would 
like to see the database be able to accomplish. What 
resulted was the schema shown in Figures 5 and 7. The 
schema presented consists of twelve tables that will store 
all of the required data. Data requirements are listed for 
each of the tables, as are the relationships that connect 
them. The Alumni Table, located within the schema, will 
store the largest amount of data, as it will serve as the 
focal point of the entire system. The alumni data required 
ranges from social security number to military branch of 
service. The primary key in this table will be AlumnilD. 
The Alumni Table is where most of an alumni's personal data 
will be stored, and is the table that will probably be used 
most frequently. The Address Table is designed to store 
the alumni's current address. The table contains AddressID 
as its primary key. This table has a one-to-many 
relationship with the Alumni Table because one alumnus can 
have many addresses. The Undergraduate Table is designed 
to store all of the alumni's undergraduate data. This 
table will store the alumni's undergraduate university 
name, the type of degree attained, and the year graduated. 
In this table the primary key is UndergraduatelD. This 
table also has a one-to-many relationship with the Alumni 
Table. The Donations Table is established to monitor the 
alumni's donation history. The primary key in this table 
is DonationsID. This table also has a one-to-many 
relationship with the Alumni Table. The AlumnusDegreeType 
and AlumnusCurric Tables are join tables in this schema. 
Join tables are established to act as conduits that allow 
data to be more easily transmitted between tables. 
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Relationships between these tables and the Alumni Table are 
one-to-many. The DegreeType Table will store data about 
the degree that the alumnus attained while attending the 
school. DegreeTypelD is the primary key in this table. 
This table has a one-to-many relationship with the 
AlumnusDegreeType join table. The Curriculum Table is 
designed to store the alumni''s curricula information when 
he attended the school. The primary key in this table is 
CurricID. This table has a one-to-many relationship with 
the AlumnusCurric join table. The Track Table is designed 
to store data on the alumni's degree track. Some NPS 
fields of study can contain several tracks that can be 
pursued, this table will store this data as it pertains to 
an alumnus. The primary key in this table is TrackID. 
This table has a many-to-one relationship with the 
Curriculum Table. The Status, State, and Country Tables in 
the schema are all look-up tables. Look up tables store 
and provide access to static data that is required in the 
database. These tables will be used to acquire the status 
(active duty, reserve, retired, deceased) of an alumnus, 
and the state and country of residence. The alumni 
database schema is shown if Figure 5. 
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Relationships 




TOR 

AdrkessD 

* 

AlumnilD 


State 


Country 


Street 1 


5treet2 


City 

— 

Zip 

d 




Under(jodUmlD 

AlumnilD 

UniversityName 

DegreeType 

Graduated 


DonabonsID 

AlumnilD 

DonationType 

DonationAmount 

LastGiftDate 

GiftPurpose 


SSN 

LastName 
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Figure 5. 


Database Schema 


D. SECURITY ISSUES 

The issue of system security is clearly an obstacle 
that must be addressed prior to implementation of any 
contracting decision. In this project, as with many other 


43 























































Internet endeavors, there are several security risks that 
can compromise system integrity. 

1. Authentication 

One of those potential hurdles is authentication. 
Because of the nature of the data that will be secured in 
the Alumni System, the ability to authenticate users is a 
vital element in this system. There are several 
authentication methods that are available for this type of 
system and each carries comparative advantages and 
disadvantages. In evaluating the possible solutions for 
the Alumni System, three methods will be studied to 
determine which provides the best fit: Basic Access 
Authentication, Digest Access Authentication, and Secure 
Socket Layer Authentication. 

Basic Access Authentication is a part of the Hypertext 
Transport Protocol (HTTP) . In this scheme, the user must 
authenticate himself with a user ID and password to access 
each realm of the system. Within each realm, protected 
resources are partitioned off with their own authentication 
databases. When a request is made for a document that 
belongs to a protected space, the server will require the 
user to authenticate himself, and then a browser will 
prompt the user for an ID and password. If this 
information is validated, the user will be allowed to 
access the data that he is requesting. Once authenticated, 
the browser remembers the ID and password, so that when 
another data request is made, the user will not have to be 
prompted again. The user IDs and passwords utilizing this 
scheme are stored in an encrypted form. 
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The advantages to using this authentication approach 
in the Alumni System primarily involve ease of use. Users 
will find this method very easy to use because it is what 
most users are accustomed to. This type of authentication 
is installed on most web server and browser software. 

A disadvantage to utilizing this method is that it is 
difficult to manage. If the Alumni System employed this 
method, each server being used would have to issue and 
securely store an ID and password for each user. 
Additionally, usernames and passwords would have to be 
prearranged manually by a system administrator, which could 
become a very time consuming process. Also, because the 
process would be a manual one, the possibility of inputting 
erroneous material would be increased. A major 
disadvantage of this scheme is that IDs and passwords would 
be transmitted over the network in the clear. This would 
permit eavesdroppers to relatively easily obtain the 
information necessary to breach the system. Basic Access 
Authentication is also susceptible to DNS and IP spoofing. 
Because clients have no way of authenticating the server, 
they are prone to security attacks. With the proper 
equipment, anyone with a strong desire to access the system 
can easily do so when this scheme is employed. 

Combining IP addresses and domain names with Basic 
Access Authentication offers a more acceptable approach. 
By employing these techniques, the Naval Postgraduate 
School could restrict access to the alumni servers by 
permitting only those requests that come from within its 
own domain to enter. This approach, however, might limit 
participation, especially since many of the proposed 
system's users would be located around the world. Using 
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the IP addresses and domain names in concert with Basic 
Access Authentication would make it more difficult to spoof 
the system, however the ability would still exist to 

penetrate the system, and subsequently there would be no 
guarantee that the person contacting the server is who he 
claims to be. 

These shortcomings render this authentication method, 
if used alone, inadequate for the Alumni System. Although 
the Basic Access Authentication scheme may keep away the 
casual surfer, it will not protect against those really 
wanting to gain access to the system. 

Another authentication method available to the Naval 

Postgraduate School Alumni System is Digest Access 
Authentication. This scheme is much like Basic Access 
Authentication, but it avoids the glaring weakness of 
sending passwords in the clear. This scheme also uses the 
challenge-response method, however, nonces are used to 
prevent replay attacks by possible system hackers. A nonce 
is a parameter that varies with time. Frequently used 
nonces are things such as time stamps and visit or usage 
counters on web pages. Because nonces change with time, 
they are used to limit or prevent unauthorized replay or 

reproduction of a file. Nonces make it easier to tell 
whether an attempt at replay or reproduction is legitimate. 
In Basic Access Authentication if an eavesdropper obtains a 
password, he normally has access to everything that is 

under the umbrella of that password, but in Digest Access 
Authentication an eavesdropper would only obtain access to 
that particular transaction, not the password or other 
information accessible by that password. In short, the 
eavesdropper could implement a replay attack, but it would 
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work only with a request for the same document, and even 
this could be made difficult with a well-selected nonce. 
Another advantage to this method is that the HTTP server 
does not actually need to know the user's clear text 
password. As long as the checksum of the user ID, the 
realm, and the password is available to the server the 
authorization header can be verified and validated. 

A possible drawback to this would occur if the 
password files are compromised, which would then give the 
hacker immediate access to all documents in that specific 
realm. There are other disadvantages to the Digest Access 
Authentication scheme as well. Like Basic Access 

Authentication, the user name and password in Digest Access 
Authentication must be prearranged in some fashion, which 
again may be very time consuming and error-prone. Also 
Digest Access Authentication is susceptible to man-in-the- 
middle attacks. This happens because there is no way for 
clients to authenticate servers in this scheme. Man-in- 
the-middle attacks are relatively simple; they usually 
happen when an attempt is made to coax the client into 
giving up its password. An example of this might occur 
after the server has received the client's request and is 
issuing a challenge. A hacker, or middleman, could 
intercept that challenge and issue another one. Not 
knowing this spoof has occurred, the client would issue a 
response that contains the user name and password, which in 
turn, would give the hacker access to the system. A final 
disadvantage to this scheme is that it cannot be used for 
any transaction that requires encrypted content, which 
would severely limit the Alumni System. 
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Although Digest Access Authentication addresses some 
of the concerns that Basic Access Authentication does not, 
it is still considered a weak authentication method. 
Digest Access Authentication will normally keep away the 
casual surfer and the mediocre hacker, but when used alone 
it still lacks in the ability to protect valuable 
information. 

A third authentication method is the popular Secure 
Socket Layer (SSL). This scheme was specifically developed 
to provide privacy and data integrity by using encryption 
and message authentication codes. SSL is designed to 
provide security for protocols like HTTP, FTP, and TELNET 
by interposing themselves between TCP and higher-level 
protocols. SSL allows client/server applications to 
communicate in a way that prevents eavesdropping, 
tampering, or forgery. One way that this scheme is used is 
when an application is summoned by the SSL to set up a 
channel. During the SSL handshake protocol, public key 
cryptology is used to authenticate the communicating 
parties and exchange session keys. An example of how this 
would be used in the Alumni System would occur when a user 
prompts the client to send the server a message requesting 
access. The server would send a certificate, which would 
include the server's public key, and the client would 
create a session key and send it encrypted in the server's 
public key so that only the server could access it. The 
remainder of the transmission would be encrypted utilizing 
the session key. Besides protecting against spoofs, 
another advantage of SSL is that it is application 
independent. This means that higher-level protocols can 
layer on top of the SSL protocol transparently. Also, SSL 
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is very adaptable, which is important to the Alumni System. 
Because it is easy to modify or add support to SSL, SSL can 
easily accommodate a significant increase in the number of 
browsers. Using a strong authentication method such as SSL 
is an adequate way to protect the information being 
exchanged in the Alumni System. This scheme would be 
especially useful when credit card donations and other 
highly secure and confidential transactions are being 
transmitted in the system. 

Increased security in the Alumni System can be 
realized by combining two or more of these three schemes. 
In choosing an authentication method that best serves the 
requirements of the Alumni System, not only authentication 
of the user and server, but also the integrity of the 
message and the degree of confidentiality should be 
considered. Obviously there is no single best scheme that 
will totally protect the system from all hackers, however 
our recommendation for providing an acceptable level of 
security is to utilize the SSL scheme to protect users who 
are transmitting secret material in the system, augmented 
by a form of Digest Access Authentication to assist in that 
protection. We believe this combination will give the 
Alumni System a secure platform to exchange information and 
ideas over the Internet. 

2. Passwords, Backups, and Packet Filtering 

Other security issues that may cause concern in the 
Alumni System are weak passwords, poor system back-ups, and 
no packet filtering. 

Passwords are a key element in the utilization of the 
Alumni System. Unfortunately, the use of passwords comes 
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with the baggage of security breaches resulting from 
compromise of those passwords. Normally passwords are a 
system's first line of defense against intruders; this is 
also true in the Alumni System, so it is imperative that 
users understand the importance of passwords. To eliminate 
or mitigate the ability for users to install weak 
passwords, or passwords that are easy to hack, a program 
should be installed that rejects any password change that 
does not meet the Alumni System's parameters. These 
parameters should contain requirements such as changing 
passwords on at least a semiannual basis, ensuring that 
passwords are not reused, and ensuring that passwords are 
made up of more than just alphanumeric characters. Efforts 
should also be made to ensure that passwords are adequately 
designed, so that they will be of the length and 
composition required to make guessing and cracking 
difficult. Users should be given ample notice and guidance 
on the creation and utilization of passwords. This will 
eliminate difficulties and bad passwords when updates are 
required. Utilization of password-generating tokens, such 
as smart cards, is also an option in this system. This is 
an easily installable and very reliable option when 
compared to the traditional password. Unfortunately 

because of the costs involved and the nature of this 
system, this option is neither feasible nor practical. We 
recommend that the Naval Postgraduate School implement an 
Alumni System that requires users to be selective in the 
creation of their passwords. Software should be installed 
that sets forth the minimum criteria required for all 
passwords, and also checkpoints should be established that 
detail when new passwords should be created. 
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How and when to back up data is a potential data 
integrity problem for the Alumni System. Unfortunately 
when an incident occurs in most organizations, recovery 
from the incident requires up to date backups, which are 
usually not as current as needed. With the Alumni System, 
backup policies and procedures should be clearly defined. 
Although the exact size of the potential system is unknown, 
it is estimated that annually the system's size and depth 
will continue to increase and will possibly approach the 
gigabyte range in the future. Although much of the data 
housed within the database would not change very often, 
because of the number of potential users, it is recommended 
that backups be done on a daily or at least weekly basis, 
and periodic checks be made at least monthly to ensure that 
information is being stored in an adequate and usable form. 
Instituting this backup policy should ensure that the 
requirements for the Alumni System are met. 

3. Firewalls and Application Gateways 

Other system requirements that need to be addressed as 
they relate to security in the Alumni System are firewalls 
and application gateways. To assist in helping to protect 
the network from attacks, a firewall should be installed in 
the Alumni System. These hardware and software 
combinations create narrow channels through which 
information flow can be tracked and controlled. Firewalls 
can usually deter most individuals who are trying to obtain 
unauthorized access, and at the very least they can warn of 
an attack or attempted attack. The firewall should be 
installed on a dedicated high performance workstation that 
is located outside of the LAN but inside of the router link 
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to the Internet. The important thing to remember here is 
that all traffic should pass through this firewall. The 
firewall that is implemented should include packet 
filtering, which is usually carried out by the router as 
data packets pass through the router's interface. When the 
router receives a packet, it examines the IP destination 
address in the packet header and forwards the packet to the 


next 

stage 

Packet 

filtering, if properly 

implemented. 

can 

act 

as a 

line 

of 

defense between the 

network and 

the 

Internet, 

which 

makes it relatively easy to filter 

out 


unwanted traffic at the router. 

In addition to firewalls that contain packet 
filtering, application gateways should also be used to 
provide more security to the Alumni System. An application 
gateway screens incoming data that is based on more than 
just the contents of a packet header. These hosts funnel 
approved users to the appropriate application server. An 
advantage of an application gateway is that it is usually 
inexpensive and less complex to manage. The combination of 
packet filtering and application gateways will provide 
additional security to the Alumni System. 

In addition to a firewall and an application gateway, 
we also recommend that a firewall monitor be used with the 
system. Firewall monitors will be able to detect potential 
problems before they become actual ones. They will be able 
to log application gateway usage and be able to report who 
is using the system and what they are using it for. These 
monitors can also assist in password security. 

E. ACCESSIBILITY 
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A major concern of those interested in the 
construction of an Alumni database is the issue of who 
should have access to the system and how much access they 
should have. After conducting an ample amount of research 
by way of interviews, surveys, and studying past systems, 
the following access levels were established for potential 
system users. A list of access levels and explanations are 
provided in Table 15, and a summary of recommended access 
levels for each stakeholder is provided in Figure 6. 
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Level/Ability/Explanation 

Level 1. Read Only. Although users with this access level 
may utilize the system on occasion, the ability to make 
changes to the system should not be granted. Having this 
level of access will allow records to be viewed. Persons 
requiring this level of access would normally be office 
clerks. 

Level 2. Read and Modify. With this access level, users 
will be able to perform all things listed under Level 1, as 
well as have the ability to make modifications to 
previously existing records. Persons requiring this level 
of access are: school alumni (on their own record), 
department heads, and executive staff, NPS Foundation. 

Level 3. Read, Modify, Create, and Delete. With this 
access level nearly all functions of the database can be 
utilized. In addition to having the access cited in 
Level's 1 and 2, Level 3 users will also have the ability 
to create and delete records. Because this level involves 
a high degree of security, this access level will be 
restricted. Persons requiring this level of access are: 
Personnel of the Office of the Registrar, Alumni Relations 
Staff 

Level 4. Total Access. With this access level everything 
available in the system is accessible. In other access 
levels there are some fields that will be hidden from the 
user, however this level will contain no hidden fields. 
Those given Level 4 access are granted system administrator 
responsibilities. Persons with this access level will be 
able to grant or deny access to potential users of the 
system. Because of the responsibility and security 
involved with this level, it will be restricted. Persons 
requiring this level of access are: Alumni Relations 
Officer, Executive Director of Institutional Advancement 
and Communications 


Table 15. Access Description List 


54 




MAJOR STAKEHOLDER ACCESS 

LEVELS 


Alumni Relations Office (ARO) 

Level 

4 

Alumni Association 

Level 

2 

Naval Postgraduate School Alumni 

Level 

2 

Naval Postgraduate School Foundation 

Level 

2 

Office of the Registrar 

Level 

3 

Department of International Programs 

Level 

2 

Naval Postgraduate School Departments 

Level 

1 & 2 

Student Services 

Level 

2 


Figure 6. Major Stakeholder Access Levels 

F. INTERACTION WITH OTHER NPS SYSTEMS 

Another key issue that must be addressed is how the 
Alumni System will interact with current Naval Postgraduate 
School systems. To ensure that effective and efficient 
integration is achieved, the proposed Harris system will 
utilize its Data Exchange System to transfer data between 
its Online Directory and the Naval Postgraduate School's 
databases. Clear and regular communication between these 
entities is necessary to ensure that a complete and 
accurate transfer of data is obtained. Prior to submitting 
the initial data file to Harris, several parameters will be 
defined by the Naval Postgraduate School to ensure that the 
data requirements are understood. The discussions will 
define the plan for the Online Directory Database plus 
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format the initial file and subsequent files transferred 
to, and obtained from, Harris. Once the submission is 
understood and accepted, data exchange will begin. As 
users make updates to the system, a daily report will be 
created, maintained, and provided to the Naval Postgraduate 
School. All data will be exchanged through a Harris secure 
file transfer site and will be made available to the 
school. To ensure that adequate security is maintained, 
the Online Directory will be made available only to those 
users who register for access to the system. The 
registration process requires user authentication that will 
attempt to prohibit unauthorized usage and viewing. During 
the authentication process, alumni will be required to 
search the database for their profile, and once their 
profile has been found, they will be required to enter a 
unique security code identifier. It is recommended that 
the name and the last four digits of the social security 
number or international identification number be used. 
Only after this is verified will users be allowed to 
establish IDs and passwords in the system for future usage. 
Harris will physically maintain the Online Directory 
Database on a secure server, while NPS representatives will 
be responsible for maintaining the content of the database 
through data transfers. 

An example of how the alumni system will interact with 
other Naval Postgraduate School systems is depicted in an 
example of how the school will conduct its Schieffelin 
Award process for the school's best teacher. Annually the 
school solicits nominations and input from its alumni and 
other participants regarding potential recipients of its 
best teacher award. Currently this process is not very far 
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reaching because many of the school's alumni are not 
contacted. The proposed system however, will greatly 
affect this process. At the onset of the award process, 
profiles of potential nominees (name, title, department, 
accomplishments/research, etc...) will be compiled from 
PYTHON and stored in a PYTHON table that is linked to the 
alumni database. A Naval Postgraduate School staffer would 
then specify a target audience based upon Online Directory 
fields. Once this information is validated, the staffer 
would then utilize a broadcast email application located 
within the alumni database to publish the information to 
alumni. Within the email, each respondent will be directed 
to an online ballot, wherein they will be requested to vote 
for faculty members who were their instructors when they 
attended NPS. The ballots and instructors are linked 
(transparently to voters) to the PYTHON database, which 
collects and tabulates statistics from the ballots to be 
presented to the Schieffelin Award Committee. An expanded 
essential use case for this process is provided in the 
appendix in Table 28. 

F. RESPONSIBILITY 

Along with having accessibility to the system, users 
will also be required to perform several tasks to assist in 
the accuracy of the system. A brief list of user 
responsibilities to the system is listed below. 

1. Level 1 

Because of the limited capabilities involved with this 
access level, there are limited responsibilities as well. 
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Users with Level 1 access are required to point out 
informational inaccuracies when they are noted in the 
system. They should also indicate system problems that are 
experienced during normal use. 

2. Level 2 

As with access criteria, the responsibilities of the 
previous level will be included in the next level's 
responsibility, so in addition to the responsibilities of 
Level 1 users, which is to ensure the accuracy of the 
system. Level 2 users are required to enter only accurate 
and verified information into the system. In the event 
that an error is discovered, persons with this level of 
access are required to correct the information or forward 
it to the next highest level. Because many of the school's 
alumni will be granted this level of responsibility it is 
important that accurate and updated information be 
emphasized. Because of the large number of potential 
records that could be stored in the Alumni System, level 2 
users must understand that their involvement and upkeep of 
the system is vital to its existence. 

3. Level 3 

Level 3 users have a critical responsibility in the 
Alumni system. These are the users that are responsible 
for the daily input and upkeep of new information being 
entered into the system. Level 3 responsibilities include 
all the responsibilities of the previous two levels plus 
the responsibility of verifying and validating all data 
prior to creating a record in the system. Also because of 
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the ability to delete records. Level 3 users are required 
to ensure that records that have been marked for deletion 
are no longer required. Level 3 users will play a big part 
in the overall success of the Alumni System. Once the 
database is populated, it is their responsibility to check 
records and ensure that they are valid, and in the event 
that they are not, they must correct or delete them. Level 
3 persons should realize that the system will only be as 
good as they make it. 

4. Level 4 

In addition to the responsibilities of all the 
previous levels. Level 4 is also responsible for adequately 
maintaining the system for utilization by authorized users. 
These users are required to make system modifications when 
needed, and they act as the direct links to maintenance 
personnel if a situation occurs that cannot be fixed by the 
Level 4 user. Level 4 users will ensure that the system is 
operational and ready for use on a daily basis. Level 4 
users will monitor the usage of the other users to ensure 
that they are adhering to their requirements and 
responsibilities to the system. 

G. SUMMARY 

In order to ensure that the requirement analysis being 
conducted for the alumni system was thorough, several 
issues had to be confronted, and throughout this chapter we 
have attempted to do that. The main stakeholders of the 
system were identified and their interactions with the 
system, as well as, the average user were detailed in use 
cases. A database schema was presented to provide a 
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foundation for how the database will look and the possible 
relationships that it may contain. Major concerns like 
security, interaction with preexisting systems, user 
access, and user responsibility were also detailed 
throughout the chapter. In addition to identifying the 
major concerns, possible remedies and recommendations were 
also provided that could alleviate or even eliminate many 
of those lingering questions that still exist about the 
Naval Postgraduate Alumni Database. Results and 
recommendations were provided to ease the fears and 
concerns of decision makers. This was done to move them 
closer to deciding in the favor of approving funding for a 
more productive system. 
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V. 


CONCLUSION 


We have thoroughly evaluated the Naval Postgraduate 
School's Alumni System as part of a process to develop a 
more effective and efficient one. To facilitate that 
effort we began by determining the central and most 
important questions and requirements for having an 
effective system. We looked at reasons why those specific 
requirements are important to the alumni system, and we 
established guides and methods for determining how to 
answer those questions and fill those system requirements. 
To ensure that we did not make the same mistakes of 
previous attempts at designing an effective system, we 
studied the history of past alumni systems. Throughout 
that process, we highlighted the problems and successes of 
those flawed systems, and established an adequate structure 
for future systems. Once we understood the possible 
problems that a new system could experience and its 
requirements, we compared and analyzed the costs and 
benefits of the options available to the Naval Postgraduate 
School. The analysis led to the choice of Harris C. 
Publishing Incorporated as the most desirable of all the 
alternatives. Overall total cost and net present value 
were among the chief factors that led to this 
recommendation. 

In addition to determining the most desirable system, 
identification of the major stakeholders in the system had 
to be accomplished. A database schema was created to 
provide a glimpse of the database's structure. 
Additionally, tables, relationships, domains, and data 
requirements were provided to assist in establishing a 
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foundation for future databases. Use cases were designed 
that detail the step-by-step process of user-system 
interaction, and provide additional assistance in 
determining and understanding the requirements of the 

system. Major security issues were addressed that identify 
the potential problems, and possible remedies to those 
issues as well. Finally, user access and responsibility 
were established to document the standards that each 

potential user will have to maintain to ensure that the 
system is successful. 

We have developed a set of high-level requirements 
that any vendor or developer can use as a basis for 

developing an alumni system. Our efforts have generated 
what we believe is an effective tool that, if used 

properly, will assist the Naval Postgraduate School in 
developing an alumni system that is robust, accurate, and 

effective. 
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VI. APPENDIX 


DATABASE SCHEMA 
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B. 


BASIC FUNCTIONS 


Ref.#/Category Functions 

Rl.l/Evident Customer must register in the system before it can be 

utilized 


Rl.2/Evident Customer must login with an appropriate social 

security number/identification number and password in 
order to use the system 

Rl.3/Hidden Verification of passwords and social 

security/identification numbers before allowing 
access to information 


Rl.4/Evident Allow for the creation of new records to the system 

Rl.5/Evident Allow for the deletion of unwanted records 


Rl.6/Evident Allow individual and group modifications to be made 

to previously existing records 


Rl.7/Hidden Provide an adequate storage mechanism 

Rl.8/Evident Provide a platform where information and ideas can be 

exchanged amongst the system's users 

Rl.9/Hidden Run queries for requested information 


Table 16. Use Case Basic Functions 
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C. BASIC USE CASES 

1. Use Case: Login 


SECTION: MAIN 


Use Case: 
Actors: 
Purpose: 
Overview: 


Type: 


LOGIN 

All System Users/Customers 
Prepare the alumni system for use 

A customer/user arrives at a computer terminal to access the 
alumni system. The user inputs and/or retrieves the required 
information. At completion, the user leaves with the generated 
information. 

Primary and essential 


Cross References: Rl.l, R1.2, R1.3 


Typical Course of Events: 


Actor Action 


System Response 


1. This use case begins when the 
customer arrives at a computer terminal 
to input or retrieve information. 


2. The user logs into the system utilizing a multi-character 
password. 

3. Acknowledges and verifies password. 
Allows user access to the system’s 
data. 

4. User proceeds to the main menu of the 
available system functions. 


Alternative Courses: 

Line 2: Invalid password entered. Indicate error upon three invalid attempts, exit the 
system. 


Table 17 . 


Use Case: Login 
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2. 


Use Case: Modify A Record 


SECTION: MAIN 


Use Case: MODIFY AN ALUMNI RECORD 


Actors: 


Purpose: 

Overview: 


Type: 


Customers: Registrar, Alumni Relations Office, School Alumni, 
NPS Foundation, NPS Departments 

To update preexisting data in the alumni database 

A customer arrives at a computer terminal to modify a record or 
records that already exist in the system. The customer inputs the 
modifying infonnation. The system records and saves the 
information. Upon completion the user exits the system. 

Primary and essential 


Cross References: Rl.l, R1.2, R1.3, R1.6, R1.7 


Use Cases: Customers must have completed the login use case. 

Typical Course of Events: 

Actor Action System Response 


1. User selects the modify a record 
option from the main menu. 


4. User inputs the required social 
security/identification number into 
the system. 


2. System asks if it is this an 
individual or group modification. 

3. System prompts user to enter social 
security number or an international 
alumni identification number. 


5. System summons the appropriate 
record. 
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Typical Course of Events Continued: 


Actor Action System Response 

6. User verifies and makes adjustments 

to the alumni record and saves the infonnation. 

7. System saves the information into 
the database. 

9. User clicks exit to leave the 
modification screen. 

10. Return user to the main menu. 


Alternative Courses: 

8. User inputs another valid social security/identification number. 


Table 18. 


Use Case: Modify a Record 
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3. 


Use Case: Delete A Record 


SECTION: MAIN 


Use Case: DELETE AN ALUMNI RECORD 


Actors: 

Purpose: 

Overview: 


Type: 


Customers: Registrar, Alumni Relations Office 

To delete a record that is resident in the alumni database 

A customer arrives at a computer terminal to remove a preexisting 
alumni record from the database. The customer recalls the record 
and removes it from the system. The system records the update. 
Upon completion the customer exits the system. 

Primary and essential 


Cross References: Rl.l, R1.2, R1.3, R1.5, R1.7 


Use Cases: Customers must have completed the login use case. 

Typical Course of Events: 

Actor Action System Response 

1. User selects the delete a record option 
from the main menu. 


2. Delete record screen appears and 
prompts user to enter social 
security number or identification 
number for international alumni. 

3. User inputs the required social 
security/identification number into 
the system and clicks delete to remove 
the record. 

4. System summons the appropriate 
record and ensures the user wants 
to delete the record. 


5. User verifies and confirms deletion. 
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Typical Course of Events Continued: 

Actor Action System Response 

7. System deletes the record, and 
saves the information into the 
database. 

8. System prompts user to enter a 
new record. 

9. User clicks exit to leave the deletion 
screen. 

10. Return User to the main menu. 


Table 19. Use Case: Delete a Record 
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4. 


Use Case: Create A Record 


SECTION: MAIN 

Use Case: CREATE AN ALUMNI RECORD 


Actors: Customers: Registrar, Alumni Relations Office, School Alumni 

Purpose: To generate a new record that will be maintained in the alumni 

database 


Overview: A customer arrives at a computer terminal to create a new record in 

the system. The customer inputs the infonnation. The system 
verifies the information and records it. Upon completion, the 
customer exits the system. 

Type: Primary and essential 


Cross References: Rl.l, R1.2, R1.3, R1.4 


Use Cases: Customers must have completed the login use case 


Typical Course of Events: 


Actor Action 


System Response 


1. User selects the create a record option 
from the main menu. 


3. User inputs the information on the new 
record. 


2. New record information screen 
appears requesting both mandatory 
and optional information. 

4. System accepts new record 

information and saves the record in 
the system. 


7. User clicks exit to leave the creation 
screen. 

8. Return user to the main menu screen. 

Alternative Courses: 

5. System rejects record and prompts user for more information. 

6. System rejects record because the record is already present in the system. 


Table 20. Use Case: Create a Record 
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5. 


Use Case: Generate Reports 


SECTION: MAIN 


Use Case: GENERATE REPORTS 


Actors: 

Purpose: 


Overview: 


Type: 


Customers: Registrar, Alumni Relations Office, NPS Departments 

To generate and print relevant alumni reports utilizing data 
obtained and compiled in the alumni database 

A customer arrives at a computer terminal to generate reports from 
the alumni system. The customer selects the topics and 
information required. The system acknowledges the information 
requested and generates the relevant report(s). Upon completion, 
the customer exits the system and leaves with the reports. 

Primary and essential 


Cross References: Rl.l, R1.2, R1.3, R1.9 


Use Cases: Customer must have completed the login use case 

Typical Course of Events: 


Actor Action 

1. User selects the print reports option 
from the main menu. 


3. User clicks type of report and selects 
the data to be included in the report. 


5. User clicks exit to leave the print 
reports screen. 


System Response 


2. Print reports screen appears 
requesting type of report to be 
generated. 


4. System accepts the selections and 
generates the required report. 


6. Return user to the main menu. 


Table 21. Use Case: Generate Reports 
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6. 


Use Case: Conduct A Survey 


SECTION: MAIN 


Use Case: 

Actors: 

Purpose: 


Overview: 


Type: 


CONDUCT A SURVEY/QUESTIONNAIRE 

Customers: Registrar, Alumni Relations Office, NPS Departments 

To solicit information from NPS Alumni regarding a specified 
topic or group of topics 

A customer arrives at a computer tenninal to solicit responses to a 
survey/questionnaire that is being conducted. The customer 
generates a list of persons to receive the survey through the 
utilization of the alumni database. The system acknowledges the 
request and generates a list of email accounts, and addresses based 
on specified criteria. The customer utilizes this infonnation to 
conduct a survey. 

Secondary and essential 


Cross References: Rl.l, R1.2, R1.3, R1.9 


Use Cases: Customers must have completed the login use case 

Typical Course of Events: 

Actor Action System Response 

1. User selects the conduct a survey 
option from the main menu. 

2. Conduct a survey screen appears 
prompting user to enter survey 
criteria 

3. User inputs the survey criteria. 

4. System accepts the criteria and 
generates the survey based on the 
criteria selected. 


5. User clicks exit to leave the conduct a 
survey screen. 


6. Return user to the main menu. 


Table 22. Use Case: Conduct s Survey 
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Figure 9. 


E. 


QUERY LIST 

Information 


obtai 


interviews, surveys, anc 
list of queries that 


system. The list is pro\ 


QUERY 

Alumni by class year 

Alumni by country 

Alumni by curricula 

Alumni by city 

Last Name query 

Graduation date query 

Alumni by race 
Alumni by military 

Email address query 

Address & state query 


Figure 10. 







DESCRIPTION 

Provides a list of alumni by class 
year 

Provides a list of alumni by 
country of origin 

Provides a list of alumni by 
curricula studied at NPS 

Provides a list of alumni by city 
of current residence 

Provides a list of alumni by last 
name 

Provides a list of alumni by date 
that they graduated 

Provides a list of alumnus by race 

Provides a list of alumnus by 
military branch 

Provides a list of alumni and 
their email addresses 

Provides a list of alumni by 
current address and state 


Query List 
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F. REPORT LIST 

Information gathered from interviews with key 
representatives, survey results, and other research aided 
in compiling a list of reports that could be required once 
a new or modified system is completed. This list is 
provided in Figure 10. 


REPORT 


Alumni by class year 


Alumni by country 


Alumni by curricula 


Alumni by city 


Last Name query 


DESCRIPTION 

Provides a list of alumni by class 
year 

Provides a list of alumni by 
country of origin 

Provides a list of alumni by 
curricula studied at NPS 

Provides a list of alumni by city 
of current residence 

Provides a list of alumni by last 
name 


Graduation date query Provides a list of alumni by date 

that they graduated 


Alumnus by race 
Alumnus by military 


Provides a list of alumnus by race 

Provides a list of alumnus by 
military branch 


Alumni by email address Provides a list of alumni and 

their email addresses 

Alumni by address&state Provides a list of alumni by 

current address and state 


Figure 11. 


Reports List 
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G. ADDITIONAL USE CASES 

1. Use Case: Alumni by Graduation Date Report 


SECTION: MAIN 


Use Case: GENERATE ALUMNI BY GRANDUATION DATE REPORT 

Actors: Customer: Student Services 


Purpose: 


Overview: 


Type: 


To generate a report that lists all NPS alumni and the date that they 
graduated from the school. 

A customer arrives at a computer terminal to generate reports from 
the alumni system. The customer selects the report parameters. 

The system acknowledges the information requested and generates 
the relevant report(s). Upon completion, the customer exits the 
system and leaves with the reports. 

Primary and essential 


Cross References: Rl.l, R1.2, R1.3, R1.9 


Use Cases: Customer must have completed the login use case 


Typical Course of Events: 

Actor Action 

1. User selects the print reports option 
from the main menu. 


3. User selects the required report from 
the options and enters additional 
parameters that may be required. 


5. User clicks exit to leave the print 
reports screen. 


System Response 


2. Reports screen appears, prompting 
user to select an option. 


4. System accepts the selections and 
generates the required report. 


6. Return user to the main menu. 


Use Case: Alumni by Graduation Date 
Report 
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Table 23. 



2. 


Use Case: Alumni by Email Report 


SECTION: MAIN 

Use Case: GENERATE ALUMNI BY EMAIL AND ADDRESS REPORT 

Actors: Customer: Alumni Relations Office 

Purpose: To generate a report that lists all NPS alumni, their email and 

current address 


Overview: A customer arrives at a computer terminal to generate reports from 

the alumni system. The customer selects the report parameters. 

The system acknowledges the information requested and generates 
the relevant report(s). Upon completion, the customer exits the 
system and leaves with the reports. 

Type: Primary and essential 

Cross References: Rl.l, R1.2, R1.3, R1.9 

Use Cases: Customer must have completed the login use case 

Typical Course of Events: 

Actor Action System Response 

1. User selects the print reports option 
from the main menu. 

2. Reports screen appears, prompting 
user to select an option. 

3. User selects the required report from 
the options and enters additional 
parameters that may be required. 

4. System accepts the selections and 
generates the required report. 


5. User clicks exit to leave the print 
reports screen. 


6. Return user to the main menu. 


Table 24. Use Case: Alumni by Email Address 

Report 
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3. 


Use Case: Alumni by Curricula Report 


SECTION: MAIN 

Use Case: GENERATE ALUMNI BY CURRICULA REPORT 

Actors: Customer: NPS Departments 

Purpose: To generate a report that lists all NPS alumni and the curricula that 

they studied while attending the school 

Overview: A customer arrives at a computer terminal to generate reports from 

the alumni system. The customer selects the report parameters. 

The system acknowledges the information requested and generates 
the relevant report(s). Upon completion, the customer exits the 
system and leaves with the reports. 

Type: Primary and essential 

Cross References: Rl.l, R1.2, R1.3, R1.9 

Use Cases: Customer must have completed the login use case 

Typical Course of Events: 

Actor Action System Response 

1. User selects the print reports option 
from the main menu. 

2. Reports screen appears, prompting 
user to select an option. 

3. User selects the required report from 
the options and enters additional 
parameters that may be required. 

4. System accepts the selections and 
generates the required report. 

5. User clicks exit to leave the print 
reports screen. 

6. Return user to the main menu. 


Table 25. Use Case: Alumni by Curricula Report 
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4. Use Case: Alumni by Country Report 
SECTION: MAIN 

Use Case: GENERATE ALUMNI BY COUNTRY REPORT 

Actors: Customer: Department of International Programs 

Purpose: To generate a report that lists all NPS alumni and their country of 

origin 

Overview: A customer arrives at a computer terminal to generate reports from 

the alumni system. The customer selects the report parameters. 

The system acknowledges the information requested and generates 
the relevant report(s). Upon completion, the customer exits the 
system and leaves with the reports. 

Type: Primary and essential 

Cross References: Rl.l, R1.2, R1.3, R1.9 

Use Cases: Customer must have completed the login use case 

Typical Course of Events: 

Actor Action System Response 

1. User selects the print reports option 
from the main menu. 

2. Reports screen appears, prompting 
user to select an option. 

3. User selects the required report from 
the options and enters additional 
parameters that may be required. 

4. System accepts the selections and 
generates the required report. 

5. User clicks exit to leave the print 
reports screen. 

6. Return user to the main menu. 

Table 26. Use Case: Alumni by Country Report 
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5. Use Case: Schieffelin Award 

SECTION: MAIN 

Use Case: RECEIVE NOMINATIONS FOR SCHIEFFELIN AWARD 

Actors: Customers: Registrar, Alumni Relations Office, NPS Foundation, 

NPS Departments, NPS Alumni 

Purpose: To solicit nominations for the Naval Postgraduate School 

Schieffelin Award 

Overview: Customers arrive at computer terminals to both solicit and provide 

nominations for the NPS Schieffelin Award. The initiating 
customer generates a survey, and the responding customer inputs a 
nomination into the system. The system compiles the list of 
nominations and generates a report. The initiating customer 
utilizes this information to recommend an award recipient. 

Type: Secondary and essential 

Cross References: Rl.l, R1.2, R1.3, R1.7, R1.8, R1.9 

Use Cases: Customers must have completed the login use case 

Typical Course of Events: 

Actor Action System Response 

1. Initiating customer accesses the broadcast 
Email application from the main menu. 

2. The broadcast email screen 
appears prompting the initiating 
customer to enter survey criteria. 

3. Initiating customer selects a target audience. 

4. System accepts the criteria. 

5. Initiating customer provides detailed 

instructions and other pertinent information 
in the broadcast interface. 

6. System prompts user to select 
either single (text, html, etc...)or 
dual (combination) message 
mode 
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Typical Course of Events Continued: 


Actor Action 


System Response 

7. The system acknowledges the 
customer’s selections and 
provides the requested message 
form. 


8. Initiating customer reviews the message 
created and submits the broadcast to all 
potentially responding customers 

9. The message is broadcasted to 
alumni per the selected criteria. 

10. Potential responding customers receive the 
broadcasted message. Customers follow the 
instructions provided, complete, and submit 
the survey. 

11. The system receives the 
submission 


12. The initiating customer selects the option 
to compile the submission. 


13. System compiles and tallies all 
submissions received 


14. Initiating customer requests report of compiled 
submission 


15. System generates the report. 


16. Initiating customer receives the report and 
clicks end to exit the report menu. 


17. Return user to the main menu. 


Table 27 . 


Use Case: Schieffelin Award 
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